重磅发布｜英国《供应商安全评估》（附原文下载）
3月22日，英国国家赛博安全中心发布《供应商安全评估》，评估网络设备的安全性，为运营商应如何评估供应商设备的安全性提供了指导。
由于网络设备的安全是任何网络安全的关键，在选择将支持关键服务或关键基础设施的设备时，客户应对该设备的安全性进行评估，并将此评估作为其采购和风险管理流程的一部分。本指南就如何评估网络设备的安全性提供了建议，它指导公共电信运营商(公共电子通信网络和服务提供商)履行“2021年电信(安全)法”规定的职责，例如要求网络提供者：在设备的采购、配置、管理和测试方面采取适当措施，以确保在设备上执行设备职能的安全。
在对网络设备进行选择决策时，应使用此指南。由于安全是一项持续进行的活动，因此应持续评估和保留供应商在设备使用期间的安全记录，为今后的安全评估提供参考。
评估方法：
通过收集关于供应商程序和网络设备安全的客观、可重复的证据来实现。
评估需要：
1. 供应商本身提供的证据。
2. 测试以验证供应商的材料。
3. 第三方证据。
附：机翻原文参考
目录
简介
评估方法摘要
外部审计和国际计划
安全研究界的支持
评估方法
供应商安全评估标准
简介
网络设备的安全是任何网络安全的关键。在选择将支持关键服务或关键基础设施的设备时，客户应对该设备的安全性进行评估，并将此评估作为其采购和风险管理流程的一部分。
本指南就如何评估网络设备的安全性提供了建议。它提供指导，支持公共电信运营商(公共电子通信网络和服务提供商)履行“2021年电信(安全)法”规定的职责，并在政府协商后最后确定“2022年电子通信(安全措施)条例”。例如，根据条例草案3.(3)(E)，将要求网络提供者：
(E)在设备的采购、配置、管理和测试方面采取适当措施，以确保在设备上执行的设备和职能的安全。
“电信安全业务守则”草案，特别是措施草案5.01和10.1提到了这一指南。虽然本指南预计不会成为该守则的一部分(最终定稿时)，也不需要或不足以满足新的供应链法律要求，但这是供应商可以用来帮助其遵守的重要建议。
在书面支持电信运营商的同时，本指南中的咨询意见也可能对依赖网络设备提供服务的关键服务或关键基础设施的其他提供者有用。NCSC承认，在网络设备支持关键服务的情况下，本文件中所建议的网络设备安全性评估的程度是最合适的。此外，为了有效地执行本文件所述的评估，客户可能需要适当的合同权利来执行建议的审核和测试。
在对网络设备进行选择决策时，应使用此指南。然而，如下文所述，安全是一项持续进行的活动。与其他业绩领域一样，客户应继续评估和保留供应商在设备使用期间的安全记录，因为这将支持今后的安全评估。
本指南没有考虑到，也不能减轻由于供应链中某个特定供应商特有的额外风险而可能产生的威胁。这些风险包括它可能受到影响或被要求采取违背客户利益或其国家安全的行动的程度。在这种情况下，可能需要对有关供应商进行额外的控制。
评估方法摘要
本文件就如何评估供应商的安全流程及其所提供的网络设备提供了指导。该方法的目的是客观地评估由于使用供应商的设备而造成的网络风险。这是通过收集关于供应商程序和网络设备安全的客观、可重复的证据来实现的。
评估供应商面临的网络风险需要：
· 供应商本身提供的证据
· 测试以验证供应商的索赔
· 第三方证据
对于本文件中的每一个标准，都可以进行一系列特定产品的抽查，并且可以通过对产品本身的实验室测试直接获得证据。这三个组件结合在一起将有助于理解供应商构建新产品的能力。
然而，这种做法永远是错误的。虽然证据将是客户驱动的，但它只能提供供应商行为的例子。为了有效，这一做法和安保标准需要维持多年，并记录良好和不良做法的证据，以支持今后的安保评估和采购决定。
在评估供应商安全做法时，NCSC建议运营商不要完全依赖供应商文档来评估供应商的安全性。安全评估应以供应商实施的安全行为为基础。这包括产品线特定的抽查，以及从产品中提取的客观证据。
外部审计和国际计划
在评估网络设备的安全性时，最大的挑战之一是生产特定于地区或运营商的产品版本的行业实践。在供应商遵循这一做法的情况下，无论是通过相互合作还是通过国际测试计划，国际客户都不能分担获得有关产品质量或安全的证据或保证的责任。
可以依靠独立的外部来源提供一些所需的证据，但条件：
· 它适用于客户的产品(特别是相同的硬件和代码库)
·所有证据都可以由客户重新确认，并随机选择了一些证据进行重新验证。
一般来说，依赖供应商文件的供应商审计或评价不太可能提供有用的证据，除非能够核实审计涉及网络设备的安全。出于同样的原因，也不应考虑审计背后的证据不广泛和可测试的审计或评价。例如，目前定义的基于纸张的私有评估是在GSMA的NESAS 1 该计划不太可能提供有用的证据来支持客户对产品安全性的评估。
安全研究界的支持
鉴于网络设备的范围、规模和复杂性，全球安全研究界(包括商业实验室和学术界)的参与对于支持客户理解安全风险至关重要。因此，应鼓励供应商对其安全做法保持透明和公开，并应鼓励它们支持负责任、独立的安全研究人员进行自己的测试和分析。
为了支持日益安全和开放的电信设备的开发，DCMS表示，它打算建立一个英国国家电信实验室(UKTL)。这将是一个安全的研究设施，将使电信运营商、现有的和新的供应商、学术界和政府聚集在一起，建立具有代表性的网络，研究和测试提高安全性和互操作性的新方法。
评估方法
评估供应商的安全方法需要采用四层方法：
Assess 评估
评估供应商提供的安全声明。这应该说明供应商的安全性方法，以及供应商对其客户做出的安全承诺。为了开发安全生态系统，NCSC建议供应商公开发布其安全声明。这为客户提供了信心，即供应商的方法对于所有客户和产品线都是一致的，并允许更广泛的安全社区参与安全讨论。
检查
针对特定的、独立选择的产品发行版，对供应商实现的安全流程进行现场检查。由于所有细节都应随时提供给供应商在他们自己的系统，提供事先通知的选择不应是必要的。
分析
对设备进行实验室测试。测试要么针对所有设备，要么从供应商提供的设备中随机选择。在可能的情况下，实验室测试应该是自动化的，这样就可以很容易地以低成本重复测试。独立于客户的实验室测试应该针对客户使用的相同的产品版本跟踪、硬件、软件、固件和配置。
维持
在整个客户与供应商的关系期间，保持供应商遵守安全声明中的标准。客户应分析问题的根源，并记录供应商的安全表现，以确保今后的评估具有严格的证据基础。
下面给出了应用这种四层方法的建议。
评估供应商的安全业绩
在评估供应商安全性时，一个重要的数据来源是供应商的安全性能。客户应考虑供应商的安全文化和行为，具体表现如下：
·供应商风险评估和安全评估程序的成熟程度
·供应商的透明度、开放性和与安全研究界的协作
·供应商评估、管理和支持客户的任何安全漏洞和事件
· 供应商遵守安全义务和要求的情况
· 供应商对产品和组件支持的方法
安全事件本身并不是不良安全做法的证据。所有大公司都可能受到安全事故的影响，根据其原因和处理方式，安全事件可能是良好做法的一个范例。客户应该考虑是否可以合理地避免事故，或者可以合理地减少其影响。
同样，产品安全漏洞或问题本身并不是不良安全实践的证据，因为这些问题将出现在所有产品中。但是，如果问题过于简单，或者由于产品管理或维护不善，这可能是实践不当的证据。
供应商安全评估标准
下表可用于协助评估供应商及其网络设备的安全程序。该表描述了客户在“安全声明”中应期望得到的信息、收集证据时应考虑进行的抽查以及客户或第三方应考虑对设备进行的实验室测试。对于抽查和实验室测试，假定客户将有充分的权限获得供应商的流程和设备，以便在根据此评估做出决策之前进行有效的评估。
当第三方被使用时，客户应该确信第三方是足够独立的，有足够的技术能力，并且获得了关于供应商日常实践的足够信息，从而为他们提供了所需的可靠证据。
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
V.A：产品生命周期管理 | |||||
五.A： 总体目标 | 供应商的产品在产品的整个生命周期内都得到适当的支持。 | 提供对产品将由供应商成熟地管理的信心，在所支持的 the product 产品展示. | 作为安全声明的一部分，供应商描述了如何支持产品。 | - | - |
五.A.1： 产品生命周期过程 | 供应商清楚地确定了每个产品的生命周期。 供应商应该有一个寿命结束策略，详细说明产品在销售结束后将被支持多长时间。 | 确保产品在指定日期前都能得到支持。此外，供应商的支持日期适用于全球，这意味着供应商很可能在整个期间继续投资于产品维护。 | 供应商在“安全声明”中描述其产品的生命周期。 对于产品线内的每一个版本，供应商在其网站上发布“销售结束日期”。“寿命终止政策”应详细说明产品在销售日期公布后的多长时间和以何种方式得到支持。此信息的位置在 安全宣言。 | 检查产品发布历史。了解供应商是如何使组件保持最新的。 | - |
五.A.2： 软件维护 | 每个产品都在其发布的生命周期内进行维护。这种维护至少涵盖了产品的安全修复。 | 确保产品能够针对产品在其支持的整个生命周期中发现的安全问题进行修补。 | 供应商清楚地描述了他们将如何在生命周期内支持产品，包括他们将在每个支持类下提供什么支持。 | 查看显示应用于产品的安全修复历史的记录，包括解决任何未解决漏洞的路线图。 | 为客户选择的产品挑选一个已知漏洞的样本，并根据供应商的策略检查这些漏洞是如何修补的以及何时修补的。(见五.A.7)。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
测试产品，以验证设备不再易受漏洞或变体的影响。 脆弱的地方。 | |||||
五.A.3： 软件版本控制 | 每个产品都有一个版本控制的代码存储库，用于记录每次代码修改。这一审计日志将详细说明： -修改、添加或删除了哪些代码 -为何作出改变 -谁做的改变 -当作出改变时 -已将哪个版本的代码内置到发布的 产品。 | 确保供应商能够准确地跟踪产品中部署的代码。这是有效调查供应链攻击的关键。 | 供应商描述了他们如何维护代码库的完整性。 | 供应商演示了如何根据正常流程进行更改，以及如何拒绝通过其他方式进行的更改。 探索一个更改并验证是否遵循了流程。 | |
五.A.4： 软件发布 | 每个产品都要经过严格的软件发布周期，包括内部测试，然后才能发布通用版本。如果软件不符合下面详述的安全工程要求，它将不会发布。每种产品应定期对其进行外部测试 一个独立的第三方。 | 存在此要求是为了确保供应商测试他们的软件版本，并验证他们的内部安全工程流程是否已被遵循。 测试还应确保以前解决的安全漏洞不会被重新引入。 | 供应商描述了他们的软件发布周期，包括网关，以及所执行的测试。 | 查看生成和测试过程。 检查针对客户选择的产品线和版本所执行的测试。检查测试工具是否配置良好，并查看测试结果。验证是否包括测试，以检查以前解决的漏洞和问题。 供应商证明，由于任何 测试失败了。 | 通过在客户或第三方实验室重复测试，检查一组供应商测试结果的准确性。 |
五.A.5： 开发过程和特性开发 | 该产品有一个主要的发布流程。 新版本的分叉被最小化。在必要时，以可选模块提供特定于客户的功能。 | 存在此要求是为了使人们相信供应商正在向他们提供产品的通用版本，因此他们知道可以使用通用支持在产品的整个生命周期内支持该产品。 路线。 | 安全声明描述了供应商的开发过程，包括如何和何时发布新产品版本，以及如何将版本数量保持在可管理的水平。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
在标准开发路线图中，任何新特性都会被引入主产品线。 | 供应商不太可能适当地支持功能特定的激增。 产品版本。 | ||||
五.A.6： 国际放行和分叉 | 供应商为每个产品维护一个单一的全局版本行。其他版本的数量最少(理想情况下没有)。 | 存在此要求是为了使人们相信产品得到了全球的支持，并且发现的任何问题都可以轻松地得到缓解。 供应商不太可能适当地支持大量特定于客户的产品。 产品版本。 | 供应商发布其产品的所有发布版本的详细信息，包括二进制哈希。预计这一信息将出现在供应商的网站上。 供应商在其安全声明中引用其产品版本的公开列表。 | 供应商描述了产品的完整发布流程，包括创建每个版本的原因。 | 根据供应商发布的信息或其他信息，测试供应商提供的产品版本是否为“全局”版本，并具有匹配的二进制散列。 |
五.A.7： 工具、软件和图书馆的使用 | 对在产品开发内部和开发过程中使用的第三方工具(例如代码编译器)、软件组件和软件库进行清点。上述任何对供应商软件的安全性都是重要的，在其整个生命周期内都会得到维护。 | 缺乏支持的工具、软件组件、软件或库不太可能使用现代安全功能。如果暴露，它们可能导致已知的漏洞嵌入到产品中。 必须修补产品关键安全保护中的漏洞，以便将漏洞最小化。 剥削的影响。 | “安全声明”描述了第三方软件组件是如何维护的，明确说明了什么时候，如果有的话，失去支持的组件将包括在任何产品版本中，并说明理由。 | 对于客户选择的产品，供应商提供了第三方组件的列表，这些组件对产品的安全性非常重要(例如，那些通过接口公开的组件)。验证这些组件是否仍在积极维护，并为产品的生命周期制定了支持计划。 | 扫描产品接口，以库存已知的第三方工具，并确定它们是否被维护。 检查产品以验证供应商的组件列表是否正确。 |
五.A.8： 软件文档 | 供应商提供最新和技术上准确的文件和新版本的产品.本文档至少应详细说明如何安全地配置、管理和更新产品。 | 这为客户提供了他们所需的信息，以帮助他们在整个网络中安全地部署和管理产品，并独立地评估该配置的安全性。 这有助于减少客户的持续依赖。 在卖主身上。 | “安全宣言”承诺向客户发布产品文档。 | 使用文档、设置、操作、配置和更新产品，而不需要供应商的支持。 | |
五.B：产品安全管理 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.B： 总体目标 | 产品将以“默认安全”的方式开发。 | 这些需求的存在是为了让人们相信，他们部署的产品是使用标准安全缓解和安全编码开发的。 技术。 | |||
五.B.1： 安全文化 | 供应商有一种确保遵守安全原则的安全文化。 | 这为公司内的开发人员提供了信心 已知遵循安全原则和开发要求。 | “安全宣言”描述了供应商内部安全文化的高级所有权，以及允许工作人员提高安全性的现有机制。 关注的问题 | - | - |
五.B.2： 安全开发生命周期 | 供应商有一个安全的DevelopmentLifecycle2来将安全性嵌入到产品开发中。所有开发团队都遵循并能够证明他们遵循安全开发生命周期过程。 | 这提供了一种信心，即在开发过程中嵌入了安全性，并且公司内部存在着一致的安全文化。 | “安全声明”描述了供应商如何开发安全产品，包括供应商如何验证其安全编码标准是否得到遵守。 | 供应商演示了他们如何获得对开发人员遵循安全开发生命周期的信心。 供应商描述了他们如何确保代码的高质量。验证产品开发中内置的安全控件示例。 过程。 | 寻找供应商在其安全开发生命周期中内置的安全控制正在工作的迹象(例如，子组件可以抵抗格式错误的输入)。 |
五.B.3： 内部构件管理 | 任何共享的内部组件或库都是最新的，并且只使用最新的稳定的、受支持的版本。这些组件和库不会针对特定的构建进行修改，并且在 产品。 | 这提供了一个信心，即在产品中使用的任何内部共享组件都将在主产品的整个生命周期中得到维护。 | “安全宣言”对维持内部组成部分作出了明确的承诺。 | 对于客户选择的产品，供应商可以列出产品的软件和硬件组件.验证仅使用最近发布的共享内部组件和库版本。探索生产线是否有分叉。 任何共享库。 | 在实验室中，验证发布的产品只包含每个内部软件组件或库的一个版本，并且所有内部组件都是最近构建的。 |
五.B.4： 外部组件管理 | 在产品中只使用受支持的外部组件。供应商监视外部组件的变更量，以便只使用最新支持的稳定版本the product 产品展示. | 这提供了这样的信心：供应商选择使用的任何第三方组件都将得到当前的支持，并且发现的任何安全问题都将得到修补。 | “安全宣言”明确承诺使用得到支持的外部组成部分。 | 对于客户选择的产品发行版，请验证它仅使用受支持的外部组件和库版本。探索当这些组件到达寿命结束时如何进行更新。 | 在实验室中，验证发布的产品只使用所有外部组件的完全支持版本。搜索内部分叉的外部组件或库的证据。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
此外，供应商监视外部组件的安全建议，并引入任何安全修补程序，并将它们集成到其产品中。 安全更新。 | 延长的支助合同可能会增加安全风险，应予以避免。 | 探索产品线是否分叉了任何外部开发的代码，如果是的话，探索如何维护它。 | |||
五.B.5： 不安全函数 | 在供应商发布的代码中没有使用不安全的函数。不安全函数是那些通常与安全漏洞相关的函数，或者是被业界认为不安全的函数。 最好的练习。 | 这些功能经常是造成产品漏洞的原因。. | “安全宣言”明确规定是否使用不安全的功能 在供应商的范围内 密码库。 | 请求使用不安全函数的代码度量标准 | |
五.B.6： 冗余和重复代码 | 供应商的源树保持在有限的冗余或重复代码的水平上。 | 冗余代码使产品更难理解和维护。增加安全关键更改不会应用于访问产品的可能性。 | “安全声明”明确说明了供应商如何生成代码以降低复杂性和提高可维护性。 | 请求关于源代码树中存在多少重复代码的代码度量标准 | |
五.B.7： 文件结构 | 供应商的源树被维护到将代码复杂度降到最低的水平，并且函数执行单一的、清晰的操作。 | 代码清晰降低了错误或漏洞的风险，并使问题更容易发现。 | “安全声明”明确说明了供应商如何生成代码以降低复杂性和增加 可维护性 | ||
五.B.8： 调试功能 | 在供应商发布的产品中没有任何工程调试功能可以削弱或绕过产品的安全机制。 | 攻击者可以使用工程调试功能来利用产品。 | 安全声明明确声明，确认在发布的版本中不存在工程调试功能。 产品。 | 请供应商演示在版本构建中包含调试功能会导致生成失败。 | |
五.B.9： 备注 | 源树通过它有合适的、可以理解的注释，解释代码的用途和 为什么它会执行它的行动。 | 注释有助于确保产品在未来能够很容易地得到支持，并加快漏洞修复的速度。 | “安全声明”明确说明了供应商如何生成代码以降低复杂性和增加 可维护性 | ||
V.C.：受保护的开发和建设环境 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.C： 总体目标 | NCSC预计该产品是在安全的环境中开发的。 | 安全的环境有助于维护产品的完整性，降低供应链攻击的风险。 | “安全声明”描述了供应商如何通过保护开发和维护其产品的完整性来维护产品的完整性。 建立环境。 | ||
五.C.1： 发展环境隔离 | 开发环境与企业网络隔离，不受互联网的保护。 | 这可以保护开发环境不受直接攻击的影响。 | 询问渗透测试或红色小组3演习的细节， 目标是修改供应商的代码基或开发 环境。 | ||
五.C.2： 建筑环境隔离 | 构建环境与企业网络隔离，不受互联网的影响。很少有人能 改变。 | 这保护了构建环境，使其免受直接攻击的危害。 | 询问渗透测试或红队演习的细节， 目标是修改供应商的构建环境。 | ||
五.C.3： 构建环境和自动化 | 构建环境很简单，构建过程是自动化的。 | 简单的构建环境和自动构建过程使产品生成。 更容易理解，不太可能有错误，减少妥协的风险。 | “安全声明”描述了如何理解和维护供应商构建过程。 | 对于客户选择的产品发行版，供应商解释构建环境及其依赖关系，并演示执行构建的自动化过程。 | |
五.C.4： 基于角色的访问 | 只有有需要的个人才能访问内部代码库，并且根据角色控制和限制访问。 | 最小化访问会减少恶意内部人员的影响。 | “安全声明”描述了供应商如何对其开发实施基于角色的访问控制 建立环境。 | 供应商演示了对开发和构建环境的访问是有限的。 | |
五.C.5： 代码评审 | 在接受之前，所有的代码都会被独立地检查。 反馈过程 存在。 | 代码评审对于维护编码标准和降低风险是必不可少的。 一个恶意的内部人。 | “安全声明”描述了供应商如何以及何时对内部代码进行审核。 还有审计。 | 对于对代码所做的任何更改，供应商可以演示如何检查或审核该更改。 | - |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.C.6： 可重复构建 | 所有发布软件的版本都可以在将来的某个日期复制。 | 复制版本允许供应商演示在过去的构建中包含了哪些组件。 跟踪每个构建，在其中内置哪些组件以及使用了哪些版本的组件，对于验证完整性至关重要。 一个建筑。 | “安全声明”明确说明了供应商如何维护他们的构建环境和代码库，以使重复构建尽可能少的差异--并对每个差异做出解释。 | 供应商复制以前的版本，并确认它在功能上与发布的版本相同。 供应商演示他们保留了构建所需的任何外部依赖项的副本。 | 将已发布的构建和再现的构建进行比较，以验证功能等效性。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
V.D.：利用缓解 | |||||
五.D： 总体目标 | 供应商实现现代产品中使用的标准安全缓解措施。 | 通过帮助减轻众所周知的漏洞类，这些缓解措施都对产品的安全性产生了明显的积极影响。现代平台、操作系统、开发语言、库和开发工具定期提供安全增强技术，以最大限度地减少安全缺陷的发生，并将其影响降到最低。 如果他们发生了。 | “安全宣言”描述了供应商关于使用防御性安全技术的政策。 | ||
五.D.1： 堆保护 | 供应商利用现代堆保护缓解措施帮助防止基于堆的内存损坏攻击。 与产品作对。 | 广泛用于使攻击者更难利用任何安全问题。 | “安全声明”指出供应商的产品是否在其整个过程中使用堆保护 产品。 | 通过(自动)检查产品以进行此缓解，以验证是否启用了堆缓解。 | |
五.D.2： 堆栈保护 | 供应商只提供使用现代堆栈缓解措施编译的可执行代码。 | 广泛用于使攻击者更难利用任何安全问题。 | “安全宣言”规定 供应商的产品是否在其整个过程中使用堆栈保护 产品。 | 通过(自动)检查产品以进行此缓解，以验证堆栈缓解是否启用。 | |
五.D.3： 数据执行预防 | 供应商支持硬件强制的数据执行预防(例如DEP或NX)。 | 广泛用于使攻击者更难利用任何安全问题。 | “安全宣言”规定 供应商的产品是否在其整个过程中使用硬件强制的数据执行预防 产品。 | 验证通过(自动)检查产品以防止数据执行的缓解措施是否启用。 | |
五.D.4： 地址空间布局随机化 | 供应商只提供使用现代ASLR技术编译的可执行代码。 | 广泛用于使攻击者更难利用任何安全问题。 | “安全宣言”规定 供应商的产品是否在整个产品中使用ASLR。 | 通过(自动)检查产品，验证地址空间层随机性缓解措施是否启用。 为了缓解这一切。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.D.5： 存储器映射保护 | 在默认情况下，供应商的产品将没有内存页映射为“Writable”和“Executable”。这不包括执行即时代码编译所需的代码区域. | 广泛用于使攻击者更难利用任何安全问题。 | “安全宣言”规定 供应商的产品是否有读写内存页。如果需要及时编译任何代码，则应在 安全声明。 | 通过(自动)检查产品，验证没有将内存页映射为可写和可执行的可执行文件的可执行文件。 | |
五.D.6： 最小特权码 | 供应商在其产品中开发和执行代码时遵循“最小特权”方法。 供应商确保他们的产品只运行在或要求达到所需的最低特权水平，以实现其所宣传的目的。如果需要更高的权限级别，则该产品将实现隔离以提高对 具体的任务。 | 以高于要求的权限级别运行的产品可以为攻击者提供攻击主机系统的路由。 | “安全声明”规定了供应商的最低要求 特权‘ 方法。 | 验证在供应商平台上运行的可执行代码是否具有最低级别的特权。 验证任何特权可执行文件在完成其特权任务后是否会丢弃特权。 | |
五.D.7： 安全改进和安全执行环境 | 该供应商计划继续 提高产品的安全性。例如，这可能包括详细说明如何以及何时计划实现安全执行。 环境4。 | 产品安全需要继续发展，以跟上威胁环境。 | 探索供应商的未来安全路线图，讨论供应商的产品安全性将如何随着时间的推移而提高。 | ||
V.E：安全更新和软件签名 | |||||
五.E： 总体目标 | 运行在设备上的代码的来源是已知的，以及在 设备是安全的。 | 减少供应商在代码生产和交付之间发生供应链攻击的风险 到设备上。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.E.1： 软件和固件签名 | 供应商的软件和固件是数字签名。 | 软件和固件的签名为开发人员生成代码提供了强有力的证据。 | “安全声明”描述了软件和固件是否经过数字签名，以及允许客户部署自己的软件和固件的任何过程。 控. | 测试提供的可执行代码(二进制文件、脚本等)是通过自动使用供应商的公共代码签名证书进行数字签名的 检查每个文件。 | |
五.E.2： 签名验证 | 在执行二进制文件之前对软件签名进行验证。 | 允许设备检查代码的源代码。 | “安全声明”描述了在执行代码之前如何检查签名。说明这张支票是否是 硬件倒置。 | 测试签名二进制文件的修改会导致设备拒绝运行二进制文件。 | |
五.E.3： 安全更新 | 更新通过设备和更新之间相互认证的安全通道传递。 服务器。 | 使用安全通道可降低攻击者利用更新机制的风险。 | “安全声明”描述更新机制的安全属性。 | 执行更新过程，验证更新是否通过安全通道传递。 | |
V.E.4 降级保护 | 当软件在安装过程中降级时，内置检测功能就会发出警报。 | 在旧版本的产品中众所周知的漏洞是利用和妥协的共同原因。 | “安全声明”描述了供应商如何防止降级攻击。 | 测试系统管理员可能会看到与当前安装的更新版本相同的签名更新是否会产生日志消息或其他警报。 | |
V.F：信任和安全引导的硬件根源 | |||||
V.F： 总体目标 | 供应商在他们的产品中使用安全的硬件信任根。它们通常被称为以下内容之一：TEE(可信执行环境)、TPM(可信平台模块)或DSC(专用安全) 构成部分)。 | 信任的硬件根使供应商能够使用现代安全缓解措施，如安全引导和代码签名。 | “安全声明”描述了供应商提供硬件支持的安全性的方法。 | ||
五.F.1： 硬件信任根 | 该设备包含一个硬件信任的来源身份和存储。 | 要提供无法被远程修改的硬件支持功能，就需要有硬件信任根。 一个袭击者。 | “安全宣言”规定了对产品的信任的任何硬件根源的存在和属性。 | - | 测试与标识或设备机密相关的私钥是否以明文形式存储在文件系统中。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.F.2： 安全启动 | 每个产品都将支持由硬件信任根(V.F.1)发起的安全启动过程，使设备在重新启动时进入已知的良好状态。 | 安全启动使设备的任何妥协都更难在电源循环之后持续。 如果设备受到破坏，则需要安全启动才能恢复对设备的信任。 否则，设备可能需要 被报废了。 | “安全声明”描述了供应商对安全引导的支持，以及在发生妥协时如何将供应商的产品恢复到已知的良好状态。 | - | 验证产品是否可以恢复到已知的良好状态。 测试在启动过程中使用的一个或多个签名二进制文件或脚本是否启动失败。 |
五.F.3： 确保JTAG的安全 | 产品上的每个计算元素都有调试接口(如JTAG和UART)。 无障碍。 | 通过物理访问，像JTAG这样的调试接口可以用来规避产品的完整性或窃取设备。 秘密。 | 测试JTAG设备无法与系统的任何JTAG抽头控制器建立通信。 | ||
V.G：安全测试 | |||||
五.G： 总体目标 | 供应商在发布前严格测试产品的安全性。 | 通过安全测试和解决，减少了产品中的漏洞数量，以及 剥削。 | “安全声明”描述了供应商在其产品范围内进行安全测试的方法。 | ||
五.G.1： 自动测试 | 一旦开发完毕，就会自动对 适用的产品。 | 这可以确保测试的规模与攻击者使用的测试规模相当。 | 安全声明描述了针对每个产品版本运行的自动化测试。 | 对于客户选择的产品发行版，请查看自动测试的测试结果。 | 客户或第三方在可能的情况下应用他们自己的自动化测试。 |
五.G.2： 测试严密性 | 开发人员不能修改构建环境以隐藏或忽略构建问题或自动测试检测到的问题。 失败的构建会自动被拒绝。 因此，在发布的产品中使用的代码不会在 建造。 | 如果允许的话，开发人员可能会试图绕过检查，从而导致更易受攻击的产品。 | “安全宣言”规定是否可以绕过试验。 | 对于客户选择的产品发行版，请查看生成结果。验证结果没有突出显示发布版本中不应接受的问题。 | |
五.G.3： 安全测试 | 对安全功能进行测试，以演示正确的操作。 | 如果安全功能实现不当，该设备可能会受到攻击. | “安全声明”说明是否执行安全测试以验证是否正确。 作战行动 | 对于客户选择的产品发行版，请查看安全性测试的结果。核实问题是否得到解决， 包括根本原因。 | 重复安全功能测试。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.G.4： 阴性测试5 | 针对每一个产品发行版进行广泛的负面测试，包括广泛的潜在故障案例、不适当的消息排序和错误的格式。 信息. | 通过使用广泛的负测试用例进行测试，供应商更有可能捕捉到容易检测到的问题。 | “安全声明”说明是否执行了否定测试，并描述了该测试的规模。 | 对于客户选择的产品发行版，请查看负面测试的测试结果。确认问题已经解决，包括根本原因。 | 对产品执行负面测试，最好是对供应商使用不同的工具集。 |
五.G.5： 模糊6 | 模糊化是针对产品执行的，特别是针对跨越安全边界的接口。这种方法很复杂。 足够确保高比例的代码是 测试过。 | 一种特定形式的负面测试，供应商根据随机生成的、格式错误的数据对他们的产品进行测试，以捕捉容易发现的问题。 | “安全声明”说明是否执行了模糊测试，并指出了测试的范围。 | 对于客户选择的产品发行版，请查看模糊测试结果以及代码覆盖率数据。确认问题已经解决，包括根本原因。 | 对产品执行模糊处理，最好是对供应商使用不同的工具集。 |
五.G.6： 外部测试 | 外部安全研究小组针对选定的主要产品版本进行测试。有些测试是不限定范围的。 | 通过将设备置于外部第三方，漏洞更有可能被检测和补救。 | “安全声明”明确详细介绍了供应商如何与外部实验室和学术界合作，以确保其产品的安全性。 独立测试。 | 要求查看外部测试的结果。确认问题已经解决，包括根本原因。 | |
五.G.7： 动态应用程序安全测试(DAST)7 | 供应商有一个Dast解决方案集成到供应商的测试过程中。 | 在测试过程中应用Dast可以识别与模糊和 阴性测试。 | “安全声明”说明供应商如何执行动态应用程序安全性测试。 | 请看Dast套房的结果。确认问题已经解决，包括根本原因。 | 对产品执行动态应用程序安全性测试，理想情况下对供应商使用不同的工具集。 |
V.H：安全管理和配置 | |||||
五.H： 总体目标 | 任何产品都可以很容易地设置成安全运行。 | 不安全配置的产品更有可能被利用。 | “安全声明”描述了供应商帮助运营商安全配置产品的方法。这包括产品是否在“安全”中发布。 配置。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.H.1： 产品硬化 | 该产品可以很容易地硬化成安全的配置。 存在帮助客户执行此强化过程的文档。如果将设备从 硬化状态。 | 不安全配置的产品更有可能被利用。 | “安全声明”规定产品是否可以很容易地硬化成安全配置。 | 验证提供的产品的安全配置是否提供了指导。 | 测试 硬化指南可以很容易地部署到产品上，而不影响必要的功能。 测试在设备脱离硬化状态时是否会创建警报。 |
五.H.2： 协议标准化 | 该产品可以配置为只使用标准化协议。 | 专有协议不允许进行彻底、独立的安全测试，也不允许 顾客。 | 分析设备的流量，以确保没有专有协议在使用。 | ||
五.H.3： 管理飞机安全 | 默认情况下，产品配置为只使用管理平面上最新的安全协议。 | 如果没有安全协议和基于用户的访问，就不可能安全地管理设备并将管理更改与 特定管理员。 | “安全声明”确认产品是否默认只使用安全管理协议. | 测试在管理平面上没有启用任何弱的或不推荐的安全协议。 | |
五.H.4： 管理访问 | 对管理平面的访问是基于用户的，并且支持基于非对称密钥的访问(例如X.509证书或SSH密钥)。 | 这允许客户限制管理权限并调查潜在的恶意更改。 使用基于非对称密钥的身份验证可以提供更安全的身份验证，并有助于降低密码的风险。 分享。 | 测试管理平面允许管理员基于用户的访问，并支持基于非对称密钥的身份验证. | ||
五.H.5： 没有未加密的协议 | 只要有可能，就使用安全协议(例如SSH和HTTPS)。如果启用了未加密协议，并且存在安全替代方案，则产品会警告管理员，并提供创建安全性的选项。 警醒。 | 防止使用不安全的协议，这增加了攻击的风险。 | 默认情况下，测试产品上没有未加密的协议和服务。 测试在产品上启用未加密协议会产生适当的警告和警报。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.H.6： 没有无证件的行政机制 | 该产品没有任何无证件的管理员帐户。示例包括但不限于硬编码密码、访问密钥对(SSH密钥)或其他管理访问。 代币。 | 未经记录的管理帐户可能在客户不知情的情况下被利用。 | “安全宣言”明确规定产品上是否有任何无证件的管理帐户。 | 在已发布的产品中搜索无文档管理员帐户的证据。 | |
五.H.7： 无无文件的行政特征 | 该产品没有任何无记录的管理功能。 | 未经记录的管理功能可能在客户不知情的情况下被利用。 | “安全声明”明确指出 产品。 | 在已发布的产品中搜索无文档管理员功能的证据。 | |
五.H.8： 没有默认凭据 | 在初始设置之后，设备上不会留下默认密码。 为了清晰起见，这也意味着供应商的软件中没有编码的管理帐户。 | 如果无法禁用任何非唯一或硬编码帐户，则该设备极易受到攻击。 | “安全声明”明确说明如何从所有设备中删除默认凭据，以及是否进行硬编码管理。 有账户存在。 | 测试初始安装后设备上没有默认凭据。 扫描产品中潜在的硬编码密码字符串。 | |
V.H.9： 良好做法指导 | 供应商明确说明了他们寻求减轻的设备受到的威胁，以及他们没有减轻的威胁。供应商提供了详细的配置，并说明了如何在 网络。 | 通过帮助理解供应商所做的安全决策，并安全地设置设备，安全错误发生的可能性更小。 | 安全声明描述了供应商进行安全分析的方法，以及他们如何支持客户最小化风险。 | 对于客户选择的产品，探索供应商的产品安全性分析，并考虑供应商是否了解风险环境并建立适当的缓解措施。 | |
V.J：脆弱性和问题管理 | |||||
V.J.： 总体目标 | 存在管理安全问题和漏洞的有效流程。这些问题得到迅速和有效的解决。 | 当发现问题时，产品最容易受到攻击，直到问题得到修补为止。 有效的问题管理减少 这种风险。 | “安全宣言”描述了供应商解决问题的方法。 | ||
五.J.1： 问题跟踪和补救 | 供应商有一个发布补救的流程。这可以确保解决所有受影响产品中的漏洞。漏洞在适当的范围内修补。 时间框架。 | 如果所有产品线的所有版本都没有解决问题，同一问题可能会继续在某些产品版本中被利用。 | “安全声明”提供了供应商解决安全问题的时间表，并描述了供应商如何跟踪所有产品的漏洞。 | 假设软件组件易受攻击，请查看包含该组件的所有产品。 | 测试以前报告并解决的漏洞是否仍可跨一系列产品被利用。 |
议题 | 安全期望 | 为什么这很重要 | 评价：安全申报 | 评估：客户或第三方抽查 | 评估：客户或第三方实验室测试 |
五.J.2： 问题理解 . | 对于问题，供应商确定问题的根源分析，并能够详细说明漏洞的来源。 | 适当的漏洞管理要求供应商了解自己的产品，并快速评估漏洞的影响。 | 对于客户选择的漏洞，供应商可以提供漏洞的详细信息、漏洞的根源以及漏洞的正确方式和时间。 解决了。 | ||
五.J.3： 脆弱性报告 | 供应商提供了一种公开宣传的方法，用于泄露与其漏洞管理相关的安全问题。 流程。 | 这使外部人员和组织能够负责任地向供应商披露安全问题。 | “安全声明”描述了如何向供应商报告漏洞。 | 了解供应商如何解决以前报告的问题。 | |
五.J.4： 问题透明度 | 供应商对他们对安全问题的修补是透明的。 | 在该部门，大多数安全问题都是在客户未意识到其存在的情况下修补的。这使得客户很难判断。 冒险。 | “安全宣言”就报告和解决的安全问题提供了衡量标准。 可以获得产品中所有修补安全问题的列表。 | ||
V.J.5 产品安全事故反应小组(Psirt)8 | 供应商已在其组织内建立了psirt结构。 | 产品安全性不限于研发。Psirt集研发、QM、TAC、OPS于一体 负责客户产品的安全操作。 | “安全声明”描述了如何与供应商的Psirt团队联系。 | 向供应商询问所选版本的产品安全事件响应计划。 | 当在实验室测试中发现漏洞时，向psirt团队报告这些漏洞，并验证供应商的响应是否有效。 |
英文原文下载链接：
https://www.ncsc.gov.uk/files/NCSC-Vendor-SecurityAssessment.pdf